reservations-eapi
Booking - Confirmation
The reservations interface exposes the underlying service's concept of provisional and its related concept of confirmed, which applies to bookings and to any subsequent booking updates (often referred to as 'after sales'). Understanding and correctly using the provisional and confirmed statuses is critical to correctly using the new reservations service.
Provisional versus Confirmed
Unlike NRS, the new reservation service works on the assumption that new data isn't applied until it has been explicitly confirmed as being valid. This provisional -> confirmed concept derives from real-world ticket sales processes, where there are usually several steps between a Customer selecting the ticket and reservation and them completing the purchase. The provisional status represents the selection stage of this process, whereas the confirmed status represents the completion of the purchase.
In more technical terms, the standard CRUD (Create/Read/Update/Delete) operations can be categorised as follows:
Action | S3 Passenger term/concept | Need confirmation? | If not confirmed? |
---|---|---|---|
Create | Create provisional booking | Yes | whole booking cancelled |
Read | Recall booking | N/A | N/A |
Update | After Sales | Yes* | Booking reverted to last confirmed state |
Delete | Cancel booking | No | N/A |
i.e. whenever a new booking is created, or a confirmed booking is updated*, it has to be explicitly confirmed otherwise the reservation service will automatically remove or revert the booking.
Impact on resources
The following shows which of the reservation resources requires confirmation in order to be applied.
Resource | CRUD Operation | Need confirmation? |
---|---|---|
/availability | Read | No |
/bookings | Create | Yes |
/bookings/{bookingReference} | Read | No |
/bookings/{bookingReference}/status - > Confirm | N/A | This is the confirm action |
/bookings/{bookingReference}/status - > Cancel | Delete | No |
/bookings/{bookingReference}/status - > Revert | N/A | Undo unconfirmed updates |
/bookings/{bookingReference}/seats | Update | Yes |
/bookings/{bookingReference}/customer | Update | Yes |
/bookings/{bookingReference}/passengers | Update | Yes |
/bookings/{bookingReference}/passengers/cancel | Update | Yes |
/bookings/{bookingReference}/legs | Update | Yes |
/bookings/{bookingReference}/legs/cancel | Update | Yes |
/bookings/{bookingReference}/legs/productItems/cancel | Update | Yes |
/bookings/{bookingReference}/rebooking | Update | Yes |
/bookings/{bookingReference}/utn | Update | No* |
/bookings/{bookingReference}/rbr | Update | No* |
/bookings/{bookingReference}/notes | Update | No* |
/bookings/references | Read | No |
/bookings/{rsid}/{serviceOriginDate}/{boardLocation}/{alightLocation}/{coachId}/{seatId} | Read | No |
/service/{rsid}/coaches | Read | No |
/service/{rsid}/coaches/images | Read | No |
/refdata/disabilityTypes | Read | No |
/refdata/discountedOrSeasonCardTypes | Read | No |
/refdata/seatProperties | Read | No |
* Note: Whilst these actions fall under the Update category the fields do not affect the validity of the booking and are considered to be metadata by the underlying service, and as such are applied immediately without needing to be confirmed.
To request updates to this text please contact Neil Barkham.